콘텐츠로 이동






php2shell AI가 발견을 도운 PHP 취약점, 무엇을 확인해야 할까

들어가며

2026년 10월 21일, PHP 핵심 런타임에서 발견된 취약점 2건을 수정하는 긴급 보안 업데이트가 공개됐습니다. 이번 취약점은 PHP2Shell이라는 이름으로 알려졌습니다. 조건이 맞으면 인증되지 않은 공격자가 서버에서 코드를 실행할 수 있는 문제입니다. 눈길을 끄는 부분은 발견 과정입니다. 보안 연구진이 AI를 활용해 취약점을 찾고, 실제 공격으로 이어질 수 있는지까지 검증했습니다. 다만 운영자 입장에서 중요한 것은 AI보다 현재 서비스의 상태입니다. 우리 서비스가 영향을 받는지, 패치가 실제 실행 환경까지 반영됐는지 확인해야 합니다.

먼저 확인할 내용

웹 요청을 처리하는 PHP 환경이라면 영향 여부부터 확인하세요.

대응의 우선순위는 패치입니다. 임시 설정만으로 대응을 마무리하면 안 됩니다.

컨테이너 환경에서는 이미지 수정뿐 아니라 실행 중인 워크로드 교체까지 필요합니다.

1. 어떤 일이 있었나?

이번 취약점은 여러 연구 주체의 신고와 PHP 개발진의 수정 과정을 거쳐 공개됐습니다.

날짜 주요 내용
2026년 8월 11일 Calif 및 OpenAI가 관련 문제 신고
2026년 8월 19일 Wiz가 취약점 최초 발견
2026년 8월 24일 Wiz가 PHP 보안팀에 신고
2026년 10월 20일 PHP 프로젝트가 긴급 보안 업데이트 사전 예고
2026년 10월 21일 취약점 공개 및 보안 업데이트 배포

주요 내용을 정리하면 다음과 같습니다.

  • 취약점 명칭: PHP2Shell
  • CVE 번호: CVE-2026-109618, CVE-2026-109619
  • 심각도: 두 취약점 모두 CVSS v4.0 기준 9.2점
  • 주요 위험: 인증되지 않은 공격자의 원격 코드 실행
  • 기본 대응: PHP 런타임 업데이트 후 실행 프로세스 교체

2. 정말 AI가 찾아낸 취약점일까?

AI를 활용해 발견한 사례는 맞습니다. 다만 “AI가 혼자 찾아내고 해결했다”는 표현은 정확하지 않습니다.

연구진이 AI를 도구로 활용해 코드를 분석하고, 취약점의 악용 가능성을 검증했습니다. 이후 PHP 개발진과 협력해 수정 작업을 진행했습니다.

누가 발견했나?

연구 주체 공개된 내용
Calif·OpenAI ‘Patch the Planet’ 프로그램을 통해 AI를 활용한 PHP 보안 분석 진행
Wiz Research 별도 연구로 관련 취약점을 발견하고 실제 악용 가능성 검증

여러 연구 주체가 독립적으로 관련 문제를 발견한 만큼, 특정 회사나 AI 모델 하나의 성과로만 소개하기는 어렵습니다.

AI는 어디에 활용됐나?

Wiz는 연구에 다음 도구를 활용했다고 공개했습니다.

  • Wiz Atlas
  • Google Gemini 4 Argon
  • OpenAI GPT-5.6 Sol

공개된 활용 범위는 다음과 같습니다.

  • PHP 코드에서 취약점 후보 찾기
  • 메모리 안전성과 요청 종료 처리 경로 분석
  • 실제 악용 가능성 검증
  • 익스플로잇 개발 지원
  • 공격 탐지와 패치 유효성 검증 지원

Wiz는 당시 최신 WordPress·Drupal·Joomla 컨테이너 이미지에서 인증 없는 원격 코드 실행을 시연했다고 밝혔습니다.

단순히 “이 코드가 수상하다”는 수준을 넘어, 실제 보안 영향까지 확인한 셈입니다.

발견 주체와 도구는 구분해서 보기

이번 사건은 연구진이 AI를 활용해 취약점을 찾고 검증한 사례입니다.

연구진의 분석, AI 도구의 지원, PHP 개발진의 수정 작업을 구분해서 이해하는 것이 좋습니다.

3. 어떤 취약점인가?

두 취약점 모두 PHP 런타임의 메모리 처리와 관련돼 있습니다.

구분 CVE-2026-109618 CVE-2026-109619
발생 지점 메모리 부족 처리 및 요청 정리 과정 비정상 요청 종료 후 내부 상태 관리
주요 원인 불완전하게 초기화된 요청 데이터 처리 해제된 메모리를 가리키는 참조가 남는 문제
취약점 유형 메모리 손상 Use-after-free
주요 영향 원격 코드 실행 원격 코드 실행 및 메모리 노출
근본 대응 수정된 PHP 런타임 적용 수정된 PHP 런타임 적용

애플리케이션 코드만 고치면 해결되는 문제가 아닙니다.

프레임워크나 CMS를 업데이트했더라도, 그 아래에서 동작하는 PHP 런타임에 패치가 적용됐는지 별도로 확인해야 합니다.

CVE-2026-109618: 메모리 부족을 처리하다 발생하는 문제

PHP 요청이 메모리 제한에 도달하면 정상 처리를 멈추고 정리 작업을 수행합니다.

이번 문제는 그 과정에서 일부만 초기화된 요청 데이터를 정상적인 데이터처럼 다룰 수 있다는 점입니다.

흐름을 단순하게 정리하면 다음과 같습니다.

  1. 요청 처리 중 메모리 부족 상태 발생.
  2. 요청 데이터가 완전히 초기화되지 않은 상태로 처리 중단.
  3. 정리 코드가 해당 데이터를 정상 상태로 취급.
  4. 메모리 손상으로 이어지고, 조건에 따라 원격 코드 실행 가능.

즉, 메모리가 부족해지는 현상 자체보다 그 상황을 처리하는 코드에 문제가 있습니다.

CVE-2026-109619: 요청은 끝났지만 참조는 남는 문제

두 번째 취약점은 요청이 비정상 종료된 뒤의 상태 관리와 관련됩니다.

요청에 사용한 메모리는 해제됐는데, PHP 내부에는 그 메모리를 가리키는 참조가 남을 수 있습니다.

  1. 치명적인 오류 등으로 요청 비정상 종료.
  2. 요청에서 사용하던 메모리 해제.
  3. 내부 상태에 이전 메모리를 가리키는 참조가 남음.
  4. 같은 작업자가 다음 요청을 처리하면서 오래된 참조 사용 가능.
  5. Use-after-free를 통해 코드 실행 또는 메모리 노출 가능.

이미 해제된 메모리를 다시 사용한다는 점이 핵심입니다.

4. 어떤 환경을 확인해야 할까?

웹 요청을 처리하는 PHP 환경이라면 점검 대상입니다.

  • PHP-FPM
  • Apache mod_php
  • php-cgi
  • FrankenPHP
  • LiteSpeed 연동 PHP
  • PHP 런타임을 포함한 컨테이너 이미지

PHP 프로젝트는 특히 mod_php 구성을 높은 위험으로 안내했습니다.

수정 버전

PHP 브랜치 취약 버전 수정 버전
PHP 8.5 8.5.11 이하 8.5.12
PHP 8.4 8.4.26 이하 8.4.27
PHP 8.3 8.3.35 이하 8.3.36
PHP 8.2 8.2.34 이하 8.2.35

PHP 8.1 이하도 영향을 받을 수 있습니다.

이전 버전을 사용한다면 배포판이나 LTS 공급자가 별도 패치를 제공하는지 확인해야 합니다.

버전 번호만 보고 판단하지 마세요

배포판 패키지는 PHP 버전 번호를 유지한 채 보안 패치만 백포트하기도 합니다.

버전 문자열뿐 아니라 공급자의 보안 공지, 패키지 릴리스 정보, 수정 이력을 함께 확인하세요.

5. 운영 환경에서는 어떻게 대응할까?

VM·물리 서버

먼저 PHP를 어디서 설치했고, 어떤 방식으로 웹 요청을 처리하는지 확인합니다.

이후 해당 공급자의 보안 업데이트를 적용하면 됩니다.

  1. PHP 설치 위치와 패키지 공급자 확인.
  2. 실제 웹 요청을 처리하는 PHP 버전 확인.
  3. 공급자 보안 공지에서 수정 패키지 확인.
  4. PHP 패키지 업데이트.
  5. PHP-FPM 또는 PHP가 로드된 웹 서버 프로세스 재시작.
  6. 서비스 기능과 오류 로그 확인.

여기서 놓치기 쉬운 부분은 프로세스입니다.

패키지 파일을 업데이트했더라도, 기존 프로세스가 그대로 실행 중이라면 대응이 끝났다고 볼 수 없습니다.

컨테이너·Kubernetes

컨테이너 환경은 호스트와 분리해서 봐야 합니다.

호스트의 PHP를 업데이트해도 이미지 안에 들어 있는 PHP는 바뀌지 않습니다. 이미지 수정부터 실행 중인 워크로드 교체까지 이어져야 합니다.

점검 대상 확인할 내용
Dockerfile PHP 베이스 이미지와 패키지 설치 방식
컨테이너 이미지 수정된 PHP 런타임 포함 여부
CI/CD 수정된 이미지가 빌드에 반영되는지
레지스트리 배포 대상 이미지에 패치가 들어갔는지
실행 중인 워크로드 새 이미지로 교체됐는지
롤백 대상 취약한 이전 이미지가 다시 배포될 수 있는지

적용 순서는 다음과 같습니다.

  1. 베이스 이미지 또는 PHP 패키지 업데이트.
  2. 애플리케이션 이미지 재빌드.
  3. 레지스트리에 새 이미지 등록.
  4. Deployment 등 워크로드의 이미지 갱신.
  5. 롤아웃 완료 및 실제 실행 이미지 확인.
  6. 서비스 정상 동작 확인.
  7. 취약한 이전 이미지로 롤백되지 않도록 배포 기준 정리.

새 이미지를 만들었다는 사실보다, 서비스가 실제로 그 이미지를 사용하고 있는지가 중요합니다.

지원 종료 버전

PHP 8.1 이하를 사용한다면 패치 가능 여부부터 확인해야 합니다.

  • 배포판·LTS 공급자의 백포트 패치 확인.
  • 패치 제공 여부가 불명확한 환경은 별도 관리.
  • 지원 중인 PHP 브랜치로 이전 계획 수립.

당장 패치를 적용하는 일과 장기적으로 지원 가능한 버전으로 옮기는 일은 나눠서 준비하는 편이 좋습니다.

6. 당장 패치하기 어렵다면?

일부 설정으로 확인된 공격 경로를 줄일 수는 있습니다.

다만 임시 완화책일 뿐입니다. 모든 공격 경로를 막는다고 보장할 수 없고, 설정 자체가 서비스에 영향을 줄 수도 있습니다.

임시 설정으로 대응을 끝내지 마세요

아래 설정은 패치 전 위험을 일부 줄이기 위한 수단입니다.

변경 전 서비스 영향을 확인하고, 가능한 한 빨리 수정 버전을 적용하세요.

CVE-2026-109618 관련 설정

일부 공격 경로를 줄이는 방법으로 다음 설정이 안내됐습니다.

memory_limit = -1

PHP 요청별 메모리 제한을 해제하는 설정입니다.

주의할 점도 있습니다.

  • 실제 메모리 할당 실패까지 막지는 못함.
  • 메모리 고갈과 서비스 장애 위험 고려 필요.
  • 요청 크기와 업로드 크기 제한도 함께 검토 필요.

메모리 제한을 없애는 설정인 만큼, 의미를 이해하지 못한 상태에서 일괄 적용하는 방식은 피해야 합니다.

CVE-2026-109619 관련 설정

확인된 일부 공격 경로에 대한 완화 설정입니다.

session.upload_progress.enabled = 0

PHP 8.5에서는 다음 설정도 일부 경로를 줄이는 데 활용할 수 있습니다.

fatal_error_backtraces = 0

적용할 때는 다음을 확인합니다.

  • 요청 파싱 전에 적용되는 설정에서 변경.
  • 변경 후 모든 PHP 작업자 재시작.
  • 전체 공격 경로가 차단된 것으로 판단하지 않기.
  • 패치가 어렵다면 외부 접근 제한이나 애플리케이션 격리 검토.

마치며

이번 사건은 AI를 활용한 보안 연구가 실제 운영 환경에 영향을 주는 취약점 발견으로 이어진 사례입니다. 운영자에게는 발견 방식만큼 대응의 마지막 단계도 중요합니다. 패키지를 업데이트했는지에 그치지 않고, 실제 요청을 처리하는 프로세스와 컨테이너가 수정된 런타임으로 동작하는지까지 확인해야 합니다.

Reference